1. What is the rationale here to "replicate" the existing CIP-0030 functionality for web wallets under a new global-level namespace rather than simply creating the handful of new API calls as an extension to CIP-0030 itself? i.e.

window.cardano.broclan.enable([130])

2. The idea of being able to use Script/Multisig addresses to interact with dApps is a good one, I would like to see more rationale and justification surrounding how dApps are expected to behave when encountering a multisig address... Is it up to the dApp to maintain the record of unsigned/unfinished multisig transactions? Should these naturally "decay" over time? Doesn't this present an issue of requiring dApps to be centralized rather than decentralized by placing this onus on the dApp to record state rather than putting the onus on the signers? Maybe a importTransaction endpoint makes sense so that members of the multisig can pass it around amongst themselves? Or the wallet provider could have a record of pending transactions somehow passed between members of the multisig?
3. We do not allow for "reservation" of CIP numbers, regardless of rationale or justification with only a handful of very notable exceptions. You should move this file to an CIPXXXX directory and await assignment of a CIP number.

1. What is the rationale here to "replicate" the existing CIP-0030 functionality for web wallets under a new global-level namespace rather than simply creating the handful of new API calls as an extension to CIP-0030 itself? i.e.

window.cardano.broclan.enable([130])

Multisig Wallets cannot implement CIP-30 since it is impossible to implement the api.signTx() and api.signData() endpoints. Implementing it as an extension of CIP-30 will lead to broken applications that try to connect to the multisig wallets and use them as if they are regular wallets.

2. The idea of being able to use Script/Multisig addresses to interact with dApps is a good one, I would like to see more rationale and justification surrounding how dApps are expected to behave when encountering a multisig address... Is it up to the dApp to maintain the record of unsigned/unfinished multisig transactions? Should these naturally "decay" over time? Doesn't this present an issue of requiring dApps to be centralized rather than decentralized by placing this onus on the dApp to record state rather than putting the onus on the signers? Maybe a importTransaction endpoint makes sense so that members of the multisig can pass it around amongst themselves? Or the wallet provider could have a record of pending transactions somehow passed between members of the multisig?

The wallet is responsible for passing the transactions among the participants, gathering the signatures, composing the final transaction and submitting it on chain, dApps need to keep track of transactions only when hidden metadata is included (only the hash is provided) since in that scenario the wallet does not have all the required information to submit the transaction

The functionality you are asking is already with "importTransaction" included with "submitUnsignedTx"

3. We do not allow for "reservation" of CIP numbers, regardless of rationale or justification with only a handful of very notable exceptions. You should move this file to an CIPXXXX directory and await assignment of a CIP number.

Done, thank you for the clarification and sorry for the confusion.

@leo42 I look forward to reading this in more detail for content. In the meantime #617 (comment) is right that we can't allow choosing CIP numbers in the present, let alone reserving them for the future: it would require a conflict resolution system that would be unmanageable because of several technical & human factors.

I have to rename it in the PR title in the meantime to avoid confusion, and also remove the redundant word "Cardano". I'm also assuming based on a quick review that, while the API strongly resembles CIP-0030, that this is a completely separate API to CIP-0030, and is therefore not an extension to it... please let me know if I'm wrong about that. cc @Ryun1

@rphair you are right, as I explained in the previous commend :

Multisig Wallets cannot implement CIP-30 since it is impossible to implement the api.signTx() and api.signData() endpoints. Implementing it as an extension of CIP-30 will lead to broken applications that try to connect to the multisig wallets and use them as if they are regular wallets.

So calling it an extension is confusing.

@leo42 I look forward to reading this in more detail for content. In the meantime #617 (comment) is right that we can't allow choosing CIP numbers in the present, let alone reserving them for the future: it would require a conflict resolution system that would be unmanageable because of several technical & human factors.

I have to rename it in the PR title in the meantime to avoid confusion, and also remove the redundant word "Cardano". I'm also assuming based on a quick review that, while the API strongly resembles CIP-0030, that this is a completely separate API to CIP-0030, and is therefore not an extension to it... please let me know if I'm wrong about that. cc @Ryun1

You are correct, implementing as an extension would would lead to problems and it is

(#617 (comment)) What is the rationale here to "replicate" the existing CIP-0030 functionality for web wallets under a new global-level namespace rather than simply creating the handful of new API calls as an extension to CIP-0030 itself? i.e.
window.cardano.broclan.enable([130])

I would first want to seriously consider this issue on both sides... on general principle (I'm not a wallet or dApp developer) I can't imagine going forward with this as written due to practically everything from CIP-0030 being duplicated & therefore prone to divergence: not only in the documentation, but even worse in behavioural inconsistencies between conventional & multisig wallets.

I agree with that I think @Crypto2099 is suggesting that the CIP call only for whatever minimum of functional differences is required by the multisigs.

If @leo42 it is a widespread problem that people are connecting with the wrong type of wallets then shouldn't we be able to settle on a definitive way of handling that though an initial query... even if some changes are necessary to CIP-0030 to support this?

I've put this on the Triage list for our upcoming CIP meeting (https://hackmd.io/@cip-editors/76) ... please @leo42 come to the meeting if you can, to help us all agree on the best footing to proceed with this 😎

@rphair I will be happy to attend if you provide a meeting link.

Discord server (CIP Editors Meetings) invitation: https://discord.gg/JtWfD4hqgz
Discord server link: https://discord.com/channels/971785110770831360
Meeting link: https://discord.com/events/971785110770831360/1164384910551818330

1. What is the rationale here to "replicate" the existing CIP-0030 functionality for web wallets under a new global-level namespace rather than simply creating the handful of new API calls as an extension to CIP-0030 itself? i.e.

window.cardano.broclan.enable([130])

Multisig Wallets cannot implement CIP-30 since it is impossible to implement the api.signTx() and api.signData() endpoints. Implementing it as an extension of CIP-30 will lead to broken applications that try to connect to the multisig wallets and use them as if they are regular wallets.

I disagree with the premise on principle. It would be quite trivial for a multi-sig wallet to only allow enable calls if the cip-130 (I know we've agreed to change the number but we'll use it for example here) extension is enabled and otherwise throw an error similar to not having a dApp account selected.

Either solution would require major overhauls for all existing dApps to account for and handle multisig wallets so it's not really a matter of one being "easier" for the dApp ecosystem to handle or not, but by making this a multisig-specific extension to CIP-30 we have less concern about maintaining feature parity when there are naturally extensions or modifications to CIP-30.

@leo42 #617 (comment) Can I add changes to another CIP as part of a single pull request ?

Yes, this is common when a CIP requires changes to data structure like the registry tables in CIP-0010 & CIP-0067. But I don't know of any examples where one CIP PR has made fundamental changes to another prerequisite CIP ... which I think we are considering here.

Generally I think these types of problems are best dealt with through versioning: e.g. "v1 of CIP-0030 doesn't discriminate properly between conventional & multisig wallets, but v2 will according to CIP-0130" (again, naming this informally).

Regardless of exactly how CIP-0030 might be versioned or extended, I believe this PR for this proposal alone should be fully reviewed & merged first.... documenting any dependencies upon further modifications to CIP-0030 in its Path to Active but without modifying CIP-0030 itself... before any future PR to extend or version bump CIP-0030. Otherwise I can imagine a serious delay in adopting multisig capability as described here because of uncertainty about breaking changes.

Hey @leo42

Thanks for this proposal.
I agree that such functionality should be pursued and added to a dApp-wallet connector.

Although, copying CIP30 endpoints under a new namespace I feel is a mistake.
I would be much more in favour to use the CIP-30 extension mechanism for this, this is the sort of thing the mechanism was added for.
Any potential problems of adding this as an extension I think are less consequential than trying to split this from CIP-30 which introduces unneeded fragmentation IMO.
If you strongly believe that this does not belong as a CIP-30 extension, I would implore you to check out CIP-90, which was an attempt to allow for extensions without the need to include CIP30 endpoints.

Looking forward to seeing how this proposal progresses.

But it will still require some changes to CIP-30 since its specifications say that all the base endpoints need to be supported and extensions only add new endpoints.

Having the base endpoints be supported doesn't mean that they can't naturally return an error if a specific wallet (i.e. multisig, Plutus script, whatever) cannot support them as-written. I would view this more like function overloading on the part of the wallet implementers rather than complete replication.

I have reworked and renamed the proposal to be a CIP-30 extension.

This will provide greater maintainability and backwards compatibility as CIP-30 continues to be updated and developed.

thanks @leo42, that definitely reflects the intentions of the CIP Editors' meeting today... @Ryun1 @Crypto2099 if you agree this is now properly integrated as an CIP-0030 extension, then I think it would be good to have on the agenda again next CIP meeting (# 77) to confirm the scope & keep it moving forward.

@leo42 an article from @Hornan7 that illustrates multisig configuration for dReps... perhaps these requirements would also influence the design of a multisig wallet API? (cc @Ryun1 @Crypto2099) https://forum.cardano.org/t/how-to-create-a-multi-sig-drep/130159

Yes we are fully compatible with this. I will build a dRrep management and registration portal using the connector so all users of BroCllan(and other providers that implement it) have the ability to participate in governance .(when I find some time )